This invention relates to a method for creating and executing computer programs. More specifically, the present invention relates to programming models and object-oriented application frameworks that are designed to facilitate the creation of distributed componentized computer programs and to support their execution in a standards-based programming environment, such as the Web-browser.
The client/server architecture describes the relationship between two computer applications in which one application, the client, makes a service request from another application, the server, which fulfills the request. Although the client/server architecture can be used by applications within a single computer, it is most commonly used as a method for establishing the relations between different computers, which are interconnected via a computer network. In these cases the client/server architecture provides a convenient method for efficiently connect applications that are distributed across different locations. A specific type of client/server architecture is the Web, in which Web-browsers requests services from Web-servers through a set of interconnected computer networks.
It is well known to skilled professionals that in order to increase efficiency, and interactivity of a client/server application, presentation operations must be done entirely at client-side. However, complete presentation management at client-side, demands increasing the complexity of the client-side software. While the average computing capacity of the common client-side computer that activates Web-applications is increasing rapidly, most of the present day solutions for Web-applications cannot fully exploit the presentation capabilities available at client-side. Due to severe security and compatibility issues there are only few solutions that employ one of the traditional (proprietary) programming platforms at client-side.
The Web-programming platform is a standard, public and widely accepted set of software standards. Web-applications that strictly adhere to these standards are guaranteed to perform well in a heterogeneous network like the Internet. The Web-programming platform derives from the document distribution service, known as the World Wide Web (WWW), which is a document-oriented programming model. In a document-oriented process, the presentation tier is divided between client-side and server-side. That is because first generation browsers were not programmable, so presentation load was handled entirely at server-side and browsers of the generations that followed do support programming, but to a limited degree that varies from one vendor to the next, so the need to compensate for their limitations at server-side still exists.
The server-side process is defined by a set of templates, which are used to dynamically generate documents as requested by clients (some of the most widely used technologies are ASP, JSP and PHP). These templates contain a combination of programming languages, which are processed partly, at the server-side (server-scripts and database-scripts) and partly at client-side (client-scripts and presentation-tags). The document-oriented programming model fosters tight coupling between client-side and server-side code, which leads to the inability to reuse presentation-code across server applications; programmers are required to reinvent presentation mechanisms and users get inconsistent interfaces. Moreover, it is extremely hard to create advanced presentation mechanisms, such as are available for desktop applications, because it is impossible to rely on already developed code components. By relying only on presentation primitives, the developers must divide the presentation across a number of documents. This creates more problems: the display flickers when users move to a different document and user-sessions need to be managed server-side, leading to non-scalable servers. Another drawback is that the generated presentation documents (known as HTML documents) contain an unpredictable mixture of presentation code, presentation tags and unstructured data. This makes it impossible to reliably extract data from Web-servers.
In order to solve a part of the problems mentioned above, new Web-standards were developed: a uniform method for structured data representation/validation/transformation (XML/XSD/XSLT), a protocol for service-oriented communications (SOAP), a language for service description (WATSDL) and a mechanism for service location and registration (UDDI). These standards form a service-oriented model, which is seated on top of the previous document-oriented model, thus naturally extending it.
The service-oriented model enables separating the client-code from the server-code. According to this model, the server-code is a black box that may change without disrupting its clients who, in turn, depend only on its description (interface). Once the service is defined, it may be refined and reused many times. This service-oriented model enables constructing sophisticated Web-applications by developing services based on other services. It is possible to do so, because server-side components of different vendor platforms can be uniformly wrapped and interact as well-defined services. Thus, the service-oriented model solves server-side integration issues. However, the need to unify the presentation tier at the client-side still exists. By following the client/server separation principle, it would be desirable not to have any presentation-code at server-side and have servers only supply Web-services. This way, presentation-code would become loosely coupled with server-code and would become reusable across server applications.
In order to achieve full client-side presentation management, the entire presentation tier must be managed within one-document boundaries. This would eliminate display flickering and the need for session management at server-side. That document can be dynamically updated in the background by using the above-described Web-services infrastructure.
Browser applications are built around one document, known as (X)HTML, containing a structure of presentation tags. This structure of presentation tags is programmatically available through a document object model application programming interface (DOM API). In other words, an (X)HTML document loaded inside a browser, becomes programmable (ready to be manipulated) through the DOM API.
An (X)HTML document can contain embedded or linked scripts to be executed by the browser. Those scripts are usually written in a high-level programming language known as ECMAScript (a language defined by a public and widely accepted standard —ECMA-262). The scripts are loaded and internally compiled by the browser. These scripts are built to use the DOM API by listening to its events and manipulating the (X)HTML presentation structure accordingly.
An application built to exploit these features would be able to made Web-server round-trips only when necessary and would be able to send only pure data over the network connection (as XML files). This way, expensive client/server roundtrips over the network, would be avoided, session state would be maintained at client-side and the presentation would become much more responsive (immediately updated without flickering).
Such a method is feasible given the current Web-programming model, but impossible to achieve in a cost-efficient manner because the underlying browser object model cannot be uniformly extended in a standards-based way. The DOM API is a closed set of objects, defined by a consortium of software vendors known as the W3C. Such a closed set of objects can never suffice; therefore, there are two extension mechanisms available: one is based on native components and the other is based on script objects. The extension mechanism, which is based on native components, forces the developer to rely on one of the traditional programming platforms. This extension mechanism is only applicable by, browser and operating system vendors (because they, can force users to regularly update their software). For independent software vendors and especially for application service providers this mechanism is extremely, inconvenient. In a Web-application, the appropriate extension mechanism to be used is therefore based on script objects.
There are always gaps between the standard DOM API specifications and the browser implementations provided by different vendors. In addition, the browser programmatic behavior is not entirely defined by the standard DOM API. However, the leading vendors supply decent substitutes. Obviously, those substitutes are not interchangeable, so scripts must be adjusted specifically for each vendor implementation of the DOM API.
A complex browser application requires many script objects. Although it is possible to separately package scripts in linked script-files, those script-files must be loaded together during the loading of the (X)HTML document, even if only a portion of them is to be used. This may prolong the start-up time, inflate the network traffic and increase the server load. Moreover, the ECMAScript language, as most other script languages, lacks the advanced language features that characterize full-featured object-oriented languages such as C++, Java, C# and VB.NET. Missing features of the ECMAScript programming language include namespaces, accessibility rules, strong types, type descriptions, type inheritance and polymorphism. Those features are essential for the development of complex software applications.
Therefore, a method for building reusable software components and a system for dynamically loading and linking them together in a browser execution environment is needed. Such a method and a system must be completely based on existing and widely accepted Web-standards in order to be client platform agnostic and to leverage existing features built into those standards, so a standards-compliant alternative to traditional programming platforms may be provided.
As explained above, the desired solution must be built on top of existing and widely accepted Web-standards. In addition, it must not contaminate them—future versions of those standards and even not-yet-invented standards, must not collide with the proposed solution.
Given the above requirements and constraints, the most reasonable possibility is to build a layer of software that would abstract away the differences in current and future browser implementations. This software layer must guarantee uniformity across supported browser implementations, i.e. transparent code porting. This software layer must be uniformly extensible—it must lay down the basic extensibility mechanisms. Somehow, application developers must be convinced to program only against this software layer and achieve that in a consistent and verifiable way. The solution is a new programming language. That programming language must complement the missing features of the ECMAScript programming language: namespaces, accessibility rules, strong types, type descriptions, type inheritance and polymorphism. Software components built with that enhanced programming language, must be loadable and processable by current browsers. That programming language should be built on top of existing and widely accepted Web-standards—the XML set of standards. This way, it would be possible to parse, validate and transform that programming language on any combination of browser and operating system. Latest generation of browsers can load, parse and transform XML content. Moreover, there are many free implementations of standalone XML parsers, XSL transformators and XSD validators, which can be used to build specialized development tools or application server frameworks.
A repository structure definition and a set of resource naming rules are required. Different types of resources must be distinguishable. Different versions of the same resource must be distinguishable. Those rules must work reasonably both in a Win32-OS and in a Unix-OS file-system. Those rules must not require special Web-server setup. In general, deployment should be smooth as file copying can be. A runtime support is required for such a programming language. That runtime must be able to load, compile, link and manage software components built with that programming language. It must provide basic services, uniformly across browser implementations; mainly resource loading, call interception and component instantiation. Loading and compiling processes must be open for change Without touching runtime's code—this way, the system can evolve With new resource loading schemes and new programming language features. New resource loading schemes might be required for new protocols. New programming language features may include generics support, aspects support, etc.
That runtime support should be natively executable by current browsers. It should rely as much as possible on existing and Widely accepted Web-standards—the ECMAScript Language Specification, the DOM Core and the DOM Range/Traversal specifications (or any other decent substitutes). The runtime should support internationalization features.
Finally, a set of system packages need to be built in order to wrap the runtime support, the DOM API and any additional (present or future) native interface. The goal is to make those interfaces appear as they were programmed using the new programming language and to close the gaps between different browser implementations.